BREAKING CHANGE for 2021.2
The following are breaking changes for the 2021.2 release.
Removal of Adapter Redis due to scheduled deprecation
The Redis adapter has been fully deprecated, and will not be included in the 2021.2 release.
The table below shows a list of adapter calls that have been removed from IAP. Our policy is to provide a deprecation notice two (2) release cycles in advance (at a minimum) before the API is removed. This list represents all deprecations announced in the 2020.2 release.
What should I do?
Review any custom apps and adapters that might reference any adapter calls on the list and change them to the replacement call (or remove them if no replacement call is given.)
| Method | Description | Deprecation Release | Scheduled Removal Release | Replacement |
|---|---|---|---|---|
| stash | Save data for a given key. | 2020.2 | 2021.2 | Consider if an Integration can be used. |
| fetch | Get data for a given key. | 2020.2 | 2021.2 | Consider if an Integration can be used. |
| fetchAll | Get all data for any key within a specific grouping. | 2020.2 | 2021.2 | Consider if an Integration can be used. |
| purge | Delete all data for a given key within a specific grouping. | 2020.2 | 2021.2 | Consider if an Integration can be used. |
| purgeAll | Delete all data for any key within a specific grouping. | 2020.2 | 2021.2 | Consider if an Integration can be used. |
Breaking change for /schema APIs
A breaking change has been added to the following four APIs:
- GET /schema/profiles
- GET /schema/integrations/:name
- GET /schema/adapters/:name
- GET /schema/applications/:name
Previously, each of these APIs would return an object which represented a JSON schema for the requested document. However, in 2021.2 each of these APIs will now return a document with the following structure:
{
"schema": {},
"decorators": []
}The previous JSON schema is now returned within the schema key, and a new property called decorators has been added. This property is used for handling encryption of keys within schemas.
What should I do?
Review any custom apps and adapters that might reference any APIs on the list. Be sure the schema key is now used to query out the schema property, instead of using the entire returned document as a JSON schema.
API removal due to scheduled deprecations
The table below shows a list of APIs that have been removed from IAP. Our policy is to provide a deprecation notice two (2) release cycles in advance (at a minimum) before the API is removed. This list represents all deprecations announced in the 2020.2 release.
What should I do?
Review any custom apps and adapters that might reference any APIs on the list and change them to the replacement call (or remove them if no replacement call is given.)
| Item | Description | Deprecation Release | Scheduled Removal Release | Replacement |
|---|---|---|---|---|
| DELETE /config/profile/delete/:id | Deletes a profile. | 2020.2 | 2021.2 | DELETE /profiles/:id |
| DELETE /config/services/delete/:name | Deletes a service config from the system. | 2020.2 | 2021.2 | DELETE /adapters/:name |
| DELETE /providers/:id | Deletes an adapter from the system. | 2020.2 | 2021.2 | DELETE /adapters/:name |
| GET /config/active_services | Get all the active services running on the system. | 2020.2 | 2021.2 | GET /adapters or /applications |
| GET /config/active_adapters | Get all the active adapters running on the system. | 2020.2 | 2021.2 | GET /adapters |
| GET /config/profiles | Get all profiles in IAP. | 2020.2 | 2021.2 | GET /profiles |
| GET /config/profiles/sync | Determines if active profile is in sync with system. | 2020.2 | 2021.2 | GET /profiles |
| GET /config/property | Get the properties of an active profile. | 2020.2 | 2021.2 | GET /profiles |
| GET /config/property/id/:id | Get the properties of a profile. | 2020.2 | 2021.2 | GET /profiles/:id |
| GET /config/property/schema | Get the properties schema. | 2020.2 | 2021.2 | GET /schema/profiles |
| GET /config/services | Get all the service configs on a system. | 2020.2 | 2021.2 | GET /adapters or /applications |
| GET /config/services/schema | Gets the service config schema. | 2020.2 | 2021.2 | GET /schema/adapters/:name or /schema/applications/:name |
| GET /config/services/sync | Determines which services are in sync with the system. | 2020.2 | 2021.2 | GET /adapters or /applications |
| GET /health/modules | Gets the health of each service. | 2020.2 | 2021.2 | GET /health/adapters or /health/applications |
| GET /health/module/:module | Gets the health of one service. | 2020.2 | 2021.2 | GET /health/adapters/:name or health/applications/:name |
| GET /modules/stop/:module | Stops a running service. | 2020.2 | 2021.2 | PUT /adapters/:name/stop or /applications/:name/stop |
| GET /modules/start/:module | Starts a service. | 2020.2 | 2021.2 | PUT /adapters/:name/start or /applications/:name/start |
| GET /modules/restart/:module | Restart a running service. | 2020.2 | 2021.2 | PUT /adapters/:name/restart or /applications/:name/restart |
| GET /providers | Get all the adapters on the system. | 2020.2 | 2021.2 | GET /adapters |
| GET /providers/:id | Gets an adapter by id. | 2020.2 | 2021.2 | GET /adapters/:name |
| GET /providers/:id/schema | Gets the specific schema for that particular adapter type. | 2020.2 | 2021.2 | GET /schema/adapters/:name |
| GET /providers/schema | Gets the schema for adapters. | 2020.2 | 2021.2 | GET /schema/adapters/:name |
| POST /config/profile/add | Creates a new profile. | 2020.2 | 2021.2 | POST /profiles |
| POST /config/profiles/change | Changes the active profile. | 2020.2 | 2021.2 | PUT /profiles/:id/active |
| POST /config/property/new | Adds a property to a profile. | 2020.2 | 2021.2 | PUT /profiles/:id |
| POST /config/property/update | Updates a profile property. | 2020.2 | 2021.2 | PUT /profiles/:id |
| POST /config/services/create | Creates a new service config. | 2020.2 | 2021.2 | POST /adapters |
| POST /config/services/save | Updates an existing service config. | 2020.2 | 2021.2 | PUT /adapters/:name or /applications/:name |
| POST /modules/load | Creates a new app during runtime. | 2020.2 | 2021.2 | None |
| POST /modules/setLogging | Set the log levels for a service during runtime. | 2020.2 | 2021.2 | PUT /adapters/:name/loglevel or /applications/:name/loglevel |
| POST /providers/schema/update | Gets the current schema for each type of adapter. | 2020.2 | 2021.2 | GET /schema/adapters/:name |
| POST /appUpdate/changeLog/ | Gets the changelog for a service. | 2020.2 | 2021.2 | GET /adapters/:name/changelogs /application/:name/changelogs |
| PUT /providers/:id | Creates or updates an adapter. | 2020.2 | 2021.2 | PUT /adapters/:name |
BREAKING CHANGE for 2021.1.1 -> 2021.2.0
Form fields with WHEN xpath condition will not get dropped from payload
As part of the 2021.2 release and maintenance releases 21.1.2 and 20.2.7, the form fields with xpath conditions will be evaluated only if the fields that are part of the expression holds any value. If the fields do not have any value in forms they will be considered as non-existent while evaluating the xpath expression. As a result of this, the exported data from forms may or may not have certain fields in the payload compared to data exported from forms in previous versions. It may also affect certain validations that are based on xpath expressions.
Child Job Loop validation of Transformations
Before 2021.1.2, if a childJob task used a loop with a transformation, and that transformation no longer existed on the system, an error would not occur until the childJob task ran. In 2021.2.0, this will now cause a validation error, putting the workflow into draft status and disallowing it from being started.
What should I do?
If an error appears related to missing transformations on a child job loop after saving the workflow or starting a job, it is recommended to update the specified childJob task with a different transformation. Alternatively, this can be fixed by re-importing the transformation, if possible.
Querying outgoing variables for childJob task that has loop properties (POST /workflow_engine/getTask)
Starting in the 2021.1.2 maintenance release, if a childJob task has loop properties set and is queried for using the POST /workflow_engine/getTask API, the returned data structure is changed to return an array of job _ids in the output's loop property. Each _id in the array references the _id of each child job started by the task. This was changed because the outgoing loop data for the childJob task can quickly become too large to handle in the platform. No other APIs were modified but will instead dereference the loop array before returning if the childJob loop task was queried for.
What should I do?
To return the full output of a childJob loop task, you can use the POST /workflow_engine/tasks/search API, which dereferences the data and returns the full output. Otherwise, the data will need to be dereferenced by getting each individual job in the array and querying for the output variables and status.
BREAKING CHANGE for 2021.1.0 -> 2021.2
Removal of "progress" key from checkIndexes API
As part of the 2021.1.1 maintenance release and 2021.2 release, the "progress" key is no longer included as part of the return data from the checkIndexes, or GET /indexes/:collection/status API. The "inProgress" key can be used to determine whether the indexes are currently being created, but the return object no longer includes data about what percentage of the index creation has been completed. Refer to the user guide of indexing for more information about configuring indexes within IAP.